home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 11⁄10⁄89 / 0050-Re DoIt Fail?-Nov89 < prev    next >
Encoding:
Text File  |  1989-11-10  |  2.0 KB  |  45 lines  |  [TEXT/GEOL]
  1. Item forwarded  by  A33          to A34
  2.  
  3. Item    3558684                         7-Nov-89        03:36
  4.  
  5. From:   ROSENSTEIN1                     Rosenstein, Larry
  6.  
  7. To:     MACAPP.TECH$                    MacApp Technical
  8.  
  9. Sub:    re DoIt Fail?
  10.  
  11. It is true that your command will have more memory available to it when DoIt is
  12. called than when I<YourCommand> is called.
  13.  
  14. It seem pretty clear what the alternatives are.  If you allocate memory in
  15. I<MyCommand> then you are more likely to run out, but if you do run out, the
  16. user hasn't lost anything.  If you allocate in DoIt, then you have more memory
  17. available, but if you fail then the user can't undo the previous command.
  18.  
  19. I think it is better to allocate in I<MyCommand> and not commit the command
  20. unnecessarily.
  21.  
  22. Another possibility is to try the allocation in I<MyCommand> and if it fails to
  23. put up an alert telling the user that memory is low, and that more memory can
  24. be gained by committingthe last command; should the application proceed?
  25.  
  26. If the user says NO, then propagate the failure.  If the user says YES, then
  27. record in your command object that the allocation needs to be tried in DoIt.
  28. Then you can retry it in the DoIt method when more memory should be available.
  29.  
  30. One enhancement for MacApp would be to keep track of the amount of memory used
  31. by a command.  Then you can test in I<MyCommand> whether committing the last
  32. command will free enough memory to allow DoIt to succeed.
  33.  
  34. You might be able to keep track of this number youself, by overriding
  35. PerformCommand and checking the free memory before and after.  (At the start of
  36. the program the amount of memory tied up in the last command is 0.  Checking
  37. the free memory before and after PerformLast command will tell you the
  38. difference in memory used by the previous and current command.)  This technique
  39. may not be 100% accurate, because committing a command might not free all the
  40. space the command allocated; some of that memory might become a permanent part
  41. of the document.
  42.  
  43. Larry Rosenstein
  44.  
  45.